Skip to main content

Reply to this post | Go Back
View Post [edit]

Poster: gsmyth79 Date: Sep 29, 2003 5:01am
Forum: etree Subject: SHN>WAV>SHN

Just playing around with it, I tried converting a shn to a wav, and then back to a shn. This new shn failed the original md5 check. Is this supposed to happen? It seems like the shn would be the exact same data as the old one and therefore should pass the old md5.

If anyone knows why this is (perhaps the md5 knows when something has been converted and then converted back) please post your ideas.


Reply to this post
Reply [edit]

Poster: Diggin Date: Sep 29, 2003 5:57am
Forum: etree Subject: Re: SHN>WAV>SHN

Were the seek tables appended?
Were they on the original?

Reply to this post
Reply [edit]

Poster: Tyler Date: Sep 29, 2003 1:30pm
Forum: etree Subject: Re: SHN>WAV>SHN

Yes, it is supposed to happen, i believe.

The reason for this is this:

When you took .shn files and converted them to .wav's ( i assume you did all this in the mkwACT toolbox?) the computer uncompresses the .shn files and makes them .wav's. Great, good stuff. Your original md5 of those original shn files, like all md5 files, is a small text file that you can open in notepad (right clikc and 'edit') to see what is inside.

For example, here's the d2 md5 of a show i taped:

33aa1125350b806b152ae1915ee8101c *bhic2003-08-10d2t06.shn
a86fd0be0b02977c041d477db6d259c6 *bhic2003-08-10d2t02.shn
ba01c869d099d454625f1d31b1eb9a10 *bhic2003-08-10d2t03.shn
c254bfb4fae9665a6179d03d1b6963be *bhic2003-08-10d2t04.shn
775ff9c7caed0ec793b2dcae9135b72e *bhic2003-08-10d2t05.shn
48a4dc07a570c55ea3573be3d8c84b9d *bhic2003-08-10d2t01.shn

see how for each track there is a unique combination of letters and numbers? when you make a .shn file from a .wav file, (generating a checksum) the toolbox after compressing the wav > shn, adds that unique checksum (the letters and numbers) to the md5, so when you have compressed say a disk of wav > shn, you have a md5 for that disk containing all those .shn files' info

So, what you did by going SHN > WAV > SHN is you were compressing the wav's to shn this fresh time, and the computer generated a whole new checksum set for each of those files. So if you still had the original md5 from the files, it would not match up to these 'new' files you just made, even though the content of the file is the same, the computer doesn't know that, it only corresponds to the original event of wav>shn that created the md5 in the first place.

I think that is how it is, but if i was too wordy or am incorrect, please someone point it out :)

also, Diana Hamilton, an Admin here and at wrote up a very comprehensive SHN FAQ. Read all you want here:

Reply to this post
Reply [edit]

Poster: greenone Date: Sep 29, 2003 2:26pm
Forum: etree Subject: Re: SHN>WAV>SHN

Not true. :)

If the file didn't change, the fingerprints should still match. The seemingly random string of letters and numbers has to be generated SOMEHOW - if a new md5 were created for every data file, then no two md5's would ever match. Try it - create and md5 for a set of SHNs, move the md5 to another directory, and then create another md5. They will be identical. The md5 is based on the data inside the file - the whole point is that if two files were identical, they would have the same md5sum.

I'd agree with TR-Brian - it's likely the removal or appending of seek tables, or perhaps a problem with non-canonical headers in the wavs that were used to create the original SHNs. Here's a thread on the etree forums that goes into a bit more detail:

And another one from HydrogenAudio:

As long as you keep the files in data format (i.e. don't burn them to CD and then try to extract them), shn>wav>shn should yield identical md5s.


Reply to this post
Reply [edit]

Poster: Tyler Date: Sep 29, 2003 2:56pm
Forum: etree Subject: Wow!

i had no clue! thanks for letting me know. that does make sense, so thanks!

Reply to this post
Reply [edit]

Poster: Diana Hamilton Date: Sep 29, 2003 11:24pm
Forum: etree Subject: Re: SHN>WAV>SHN

Layman explanation:

Before 9/2000, all versions of Shorten software worked identically, just simply decompressing and recompressing. If it had stayed that way all shn1>wav>shn2 processes would have produced matching checkums, shn1 = shn2.

But after that it got complicated. Some Shorten software stayed simple, some got fancier with what it does, and now the equation is not always true.

This post was modified by hamilton on 2003-09-30 06:24:31

Reply to this post
Reply [edit]

Poster: gsmyth79 Date: Sep 30, 2003 1:32am
Forum: etree Subject: Re: SHN>WAV>SHN

Thanks for all the input folks. I fell a little bit more knowledgeable about this stuff now.

I haven't tried this, but I assume you could do flac>wav>flac with no problem? From all I've read about it flac definitely seems the way to go, with smaller compression and internal checksums, etc. Hopefully it starts catching on more...

This post was modified by gsmyth79 on 2003-09-30 08:32:01

Reply to this post
Reply [edit]

Poster: Diana Hamilton Date: Sep 30, 2003 1:39am
Forum: etree Subject: Re: FLAC>WAV>FLAC

I assume you could do flac>wav>flac with no problem

Heh, you would get the same internal wav checksum (output as ffp.txt) but not necessarily the same whole-file checksum. That software's even fancier with what properties you can change...